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ABSTRACT 


With the shift from batch applications to online svstems supporting the strategic 
role of information, corporate or institutional goals tie directly to the information man- 
agement functions. This has been true at the Naval Postgraduate School (NPS). Like 
many other Government installations, the NPS Computer Center has to meet its objec- 
tives with less than state-of-the-art hardware. In the early 1980's, the Center employed 
IBM's 3850 Mass Storage Subsystem (MSS) for online storage of student and faculty 
data sets. It was installed in December 1980 and performed well for over six years. 
Faced with IBM’‘s announcement (in February 1985) of the limited future connectivity 
and compatibility and the increasing maintenance costs, the decision was made to re- 
place the MSS with a hardware software alternative that would use a more modern and 
reliable architecture. The objective of this thesis 1s to define the solution, the data set 
migration process, and describe the early experience with a mulu-level, software- 


managed, storage system. 


TABLE OF CONTENTS 


1... ENTRODUCTION SS... 0101111667 1 
Il... INFORMATION STORAGE-BACKGROUND ...................... 2 
111 - MASS STORAGE SYSTEM AT PS C cC ٦ 7 


IV. STORAGE MANAGEMENT NEEDS-HOW DFHSM SATISFIES THE ٦ 


An SPACE E oss. n NIRE  . .._- 15 
B. DATA MANAGEMENT T "VC , ٹ6 مسيیي ي ي,‎ 16 
C; SUMMARY CC EM LU VOU ERE ٣ک کک کک‎ 17 
TEMPLE MEN TA TO een ys 1 1 19 
A. CATALOG CONVERSION T a 19 
B. USER DATASET EVALUATION AND BACKUP ................. 21 
Es "SOFTWARE INSTALADO کو9‎ 99199 ٤ 22 
D. MIGRATION ۰ 9898 0899 پ9‎ پ٦٣‎ 22 
E. MONE YEARLATERT کٹ بب‎ 24 
APPENDIX A. SPACE AND USAGE ANALYSES OF NISS VOLUMES ۲ 28 
A SPACE کو ےی جم‎ ۷۶9 3+ + ٔ ٤ 25 
Do USAGE کئىصئںىئى8.-ء ص۹۹ )۰ءء بر‎ 30 
ADDENDES B. ۸00 ک0‎ 111 35 
LIST OF REFERENCES a e ee 37 
INITIAL DISTRIBUTION CIST ss. ١ 39 


Table 


Table 


Table 


Table 


Table 


Table 


Table 


Table 


Table 


A Ww N سم‎ 


LIST OF TABLES 


CHARACTERISTICS OF STORACE DEMICES SESI 0 A 5 
7 TOPAZ eSE RS OR STORAGE TEES OS: ass ن‎ 26 
<- COMPARISON OF THE USE OFPMMASS STORAGE—1986-1988 .... 28 
. SPACE UTILIZATION BY DAYS SINCE LAST 

AE A TAUTA s zs Raub a aedes 29 
SEFREEN TAGE OFDATASETS OPEN ARIOESSIZES FOR 1986 TO 

SP A AS ae ee 30 
SDSIRIBETION OF DATSSEISFORUESERSWITH OVER 300 CPU 

EOE S ہی ا ا‎ A RC جم سان‎ Su 
“DISTRIBUTION OF DATA SETS FOR"USERS WITH 101-200 CPU 

HOURS E een ee an le 5» 
. DISIRIBUTION OF DATA SE1S FOR USERS WITH 51-100 CPU 

E O RS STEP RET NT NE ettet s 33 


. DISIRIBUIION OF DATA SEIS FOR USERS WIIH 25-50 CPU 


E A a M dme D gd 34 


LIST OF FIGURES 


Figure 1. Information Storage Hierarchy 1 0 "MI ٤ 


Figure 2. Mass Storage System Configuration MM 


V1 


ACKNOWLEDGEMENTS 


I wish to express mv gratitude and deep appreciation to all those people whose as- 
sistance and support have enabled me to complete this thesis and the courses which were 
required for this degree. Much gratitude goes to my supervisor, David Norman, for his 
technical support and for insisting that I perform every step that I possibly could in the 
process of this conversion. In so doing. I learned much more than anv regular student 
could have done. Without his friendship, support, and sharing of expertse, the project 
would have bogged down at many points. I owe Professor Doug Williams, Director of 
the W. R. Church Computer Center, much for his perfectionist eye which enabled me 
to present my work in a more polished and professional manner. The work he did as 
mv advisor was done on his own time, not as part of his job. I owe Ruth Roy a great 
deal for teaching me how to use SAS for the analvses in the follow-up portion of my 
project, but more so, I owe her for the moral support needed when I was tired and dis- 
couraged. She, more than anv other friend, helped keep mv eve on mv long term goals. 

To my children, Kirsten and Andv, I owe much thanks and more for accepting mv 
goals and allowing me to be mother and student, without shortchanging either vocation. 
And, to mv husband, Charlie, I owe the greatest debt, for supporting me and encour- 


aging me in all that I do, to accomplish much more than I thought I could. 


vil 








I. INTRODUCTION 


Data processing has evolved from primarily accounting-oriented applications to the 
support of integrated information systems. Conversion from batch applications to on- 
line management information systems directly ties institutional goals to these informa- 
tion management functions. The efficiency of this management directly impacts an 
institution's success. This has been true at the Naval Postgraduate School (NPS). As 
with many other Government installations, the NPS Computer Center has to meet 1ts 
objectives with less than state-of-the-art hardware. The number and size of the data sets 
belonging to the students, staff, and facultv of NPS, tenant commands, and other users 
of the NPS Computer Center was a good fit for the IBM 3850 Mass Storage Subsvstem 
(MSS). The MSS was installed in December 1980, between academic quarters, and 
functioned effectively for six-and-a-half vears. IBM announced in February 19$5 that 
no mainframe Central Processing Unit (CPU) beyond the model 3090 would support the 
MSS. [Ref. 1] This fact plus the increasing maintenance costs ($82,000 for 1985) caused 
the Center's management to explore alternative hardware, software solutions for a more 
modern and reliable architecture which promised future connectivity as well. The ob- 
Jective of this thesis 1s to define the solution and the NPS Computer Center's migration 
to it. The thesis covers all aspects of the complex process from planning and estimation 
of storage requirements, data set migration, and post-installation experience with the 
new system. All steps in the installation process were performed by the author unless 


otherwise noted. 


Il. INFORMATION STORAGE—BACKGROUND 


In a large system environment, information management depends crucially on cost- 
effective information storage and retrieval. In the 1980's, with the explosive growth of 
machine-readable information, various data storage systems have evolved. The current 
options may be portrayed as a storage hierarchy (Figure 1 on page 3) with each level in 
the hierarchy having different levels of performance, capacity, and price. [Ref. 2, 3, and 
4} Many writers define this hierarchy with greater or fewer levels depending upon the 
products supported by the writer's company. One author had a bottom laver of printed 
output for data stored in hard-copy form. As storage devices change, the hierarchy may 
change in implementation, but these general categories will remain with new levels de- 
pendant on cost/performance factors added with technological advancement. The ori- 
entation of this thesis is toward the IBM large systems storage hierarchy. Other venders’ 
svstems use different approaches. 

After processor storage, the top level in today’s hierarchy 1s high-performance 
direct-access storage device /DASD, (solid state) which was first delivered in 1979 to 
facilitate system paging, a major performance bottleneck in modern systems. Today's 
online, response-oriented systems require high subsystem availability which can be met 
bv solid-state devices having relativelv few mechanical components. Solid-state (non- 
rotating) DASD is a top performer. Its consistent I/O response time of 0.3 milliseconds 
(ms) satisfies between 300 and 400 I O requests per second per IO path. (Ref. 2, 3, and 
4] With the introduction of the 3380 disk storage image in 1984, faster response time for 
a broad range of online applications became a possibility. According to Mr. Fred 
Moore of StorageTek, "The provision for device images that mirrored rotating DASD 
may have been the most significant enhancement for high-performance DASD.” The 
new format allowed the portability of data between real 3380-class DASD and high- 
performance 3380 without converting blocksizes or changing space allocations via job 
control language (JCL). Since 1984, solid-state DASD has become the preferred sol- 
ution for response-critical applications. Although the most costly, the possibilities of 
100 percent space utilization and 70 percent channel utilization could make the efficiency 
of this architecture COs- elc cuva RC?) 

The second level in the storage pyramid is cached DASD controllers whose accept- 


ance has steadily grown throughout the 1980s. Cached controllers serve as high 
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Figure l. Information Storage Hierarchy 


performance holding areas for data that have high READ hit ratios. A WRITE 
operation must always go to the physical DASD volume for data integrity. A cached 
subsystem can provide a more consistent response for the attached DASD subsvstem 
(0.3 - 1.0 ms service time) and can improve channel utilization above the typical 35 
percent busy threshold for non-cached DASD. With the growth of online and 
response-critical applications, the use of cache has spread rapidly. Some applications 
which would be good choices for cached DASD are read-only data sets and databases, 
database indices, pageable link pack area (PLPA), and catalogs. [Ref. 2] In IBM s hi- 
erarchy [Ref. 3] high-performance cached DASD subsystems are represented by IBM 
3880 and 3990. The IBM 3880 Model 11 and Model 13 subsvstems contain two cached 
storage directors and a subsystem storage unit with 3350 disks for the Model 11 for 


paging applications and with 3380 disks for the Model 13 for non-paging applications. 


Each storage director attaches to 3-megabytes-per-second, data-streaming channels to 
attach to DASD. The IBM 3990 Storage Control family replaces the IBM 3880 Storage 
Control Models 3 and 23. It offers improved price, performance, service, and function 
over the 3880 and is available in six models: two without cache and four with cache. 
Five of the models offer four-path access to the new IBM 3380 Enhanced Subsystem 
DASD. All models attach to the new J and K models as well as older models of IBM 
3330 DASD. [Ref 5] 

The third level in the hierarchy is rotating DASD, the primary online storage device 
in almost all computer systems. IBM reports that in 1978, the median number of 3380 
disks per IBM installation was approximately nine volumes. This number had grown to 
over 150 volumes by 1985. [Ref. 6] DASD use has grown at 35 percent annually [Ref. 
2] and is predicted to continue its rapid growth at over 30% annually [Ref. 7] or to as 
much as 45% for some installations [Ref. 6]. DASD satisfies both online and batch re- 
quirements with adequate performance capacity and non-volatllity. A GUIDE survey 
published in late 1984 indicated that the amount of allocated space per access mech- 
anism was declining steadily. [Ref. 2] Users have allocated less data per access mech- 
anism to reduce contention and thereby maintain acceptable performance levels. IBM 
[Ref. 7] predicted that DASD and processor speeds will increase sufficiently to allow the 
user to allocate 3.5 times the amount of data for comparable response times in the 
1990-1995 timeframe. 

The fourth level in the hierarchy is mass storage. In the late 1960s IBM introduced 
the 2321 Data Cell for large computer users. Several mass storage products have been 
introduced since that time though none have yet become dominant for mass storage. 
At the Naval Postgraduate School, the IBM 3850 Mass Storage Subsystem filled this 
niche from December 1980 until July 1987. Whereas in the first three levels of the hi- 
erarchy, access times are measured in milliseconds, the access time for the mass storage 
device is measured in seconds. Mass storage subsystems have had problems with reli- 
ability and availability to the extent that some companies have discontinued them. 
Some systems, like IBM’s MSS, have used a combination of accessors (picker arms) and 
data recording devices to transfer data from unique data storage cartridges or high- 
density video tape stored in a library to staging devices. Other mass storage systems use 
some industry-standard media, such as 9-track tape reels or the 18-track cartridges, 
which allow the tapes to be read or written on any compatible drive when there 1s a 
subsystem hardware or software failure. In recent years, the successful application of 


robotics in mass storage subsystems, along with the ability to connect several 


subsvstems together, gives creators of these systems hope for extensive future use. [Ref. 
2| Mass Storage Systems should provide: 

e Relatively quick access 

e Data access compatible with systems software and access methods 

e Technologies which can be enhanced to provide long-term storage solutions 

e System accessible storage media 


* Cost effectiveness not onlv in price but operational and environmental measures. 


Table I summarizes the relationships between these levels in the hierarchy. [Ref. 2, 4, 
8, 9, and 10] 


Table 1. CHARACTERISTICS OF STORAGE DEVICES 
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The bottom level of the hierarchy ıs magnetic tape. This removable, portable me- 
dium has been the choice for over 20 vears for backup, archiving, and transportability. 
Today, the newer, 18-track cartridge tape subsvstems with its 200 megabytes capacity 
and negligible errors are replacing the traditional 9-track, reel-to-reel tapes which hold 
160 megabytes. Mr. Moore forecast [Ref. 2] increasing the 18-track to a 36-track tape 
and using longer tapes which could increase the capacity of each cartridge to 1.0 
gigabytes. 

As information becomes more strategic to business, so does the question of recovery 
from loss of such information. Unlike DASD, tape capacity for business applications 
is virtually limitless. There will always be a need for this level in the hierarchy and tape, 
in some form, will be the medium to fit the requirements for many years to come. 

If the requirement exists for immediate availability, the data would need to reside 
on high performance DASD—or the top level of the hierarchy. Level three, DASD, is 


the choice if a few milliseconds in additional response time can be tolerated. It would 


be desirable to have everything instantly accessible but the high cost 1s not necessary for 
most data. Mass storage systems satisfy the requirement for lower cost but with an in- 
itial service time of several seconds. According to Mr. Moore, “what remains to be seen 
is a truly successful implementation” of a mass storage subsystem. He also predicts that 
although the “challenge of managing more than 1,000 gigabytes of online data will be 
aided to some degree by technology advances, ... the major responsibility will fall heavily 
into the area of software.” [Ref. 2] The reliance only on a hardware hierarchy will cease 
as software plays an increasingly important part in the future. The requirements of such 


software will be addressed in Chapter IV. 


Ill. MASS STORAGE SYSTEM AT NPS 


When the IBM 3850 Mass Storage Subsystem (MSS), was first marketed by IBM 
(Oct 9, 1974), the total volume of data collected and maintained by many customers 
exceeded the maximum configuration of then-current DASD. While the IBM 370,168 
processors and 3350 DASD were relatively new, IBM announced the MSS as a tape re- 
placement providing almost unlimited data storage online and at a very low cost [Ref. 
11]. At the time, the only alternative was massive off-line tape libraries. There are manv 
drawbacks to using tapes. Data stored on tape is inherently sequential, so random or 
directly processing individual records is impractical. Tape volumes are not mounted 
until thev are required, as opposed to most DASD devices, which tend to remain more 
or less permanently mounted. This implies human intervention, which causes both a 
time delay in mounting the tape and a greater potential for error in handling than is 
typically encountered with DASD. A tape can onlv be accessed by the job that called 
for it, unlike a file on DASD which can be shared by multiple processors at the same 
ume. 

There was a great need for a mass storage system with a large data storage capacity 
which would be under system control, and have the data organization flexibilitv of 
DASD. It needed to have “current” DASD transfer rates and a cost per megabvte of 
storage closer to that oftape than DASD. When IBM announced the IBM 3850 Mass 
Storage Subsvstem, it met these requirements with sophisticated technologv extending 
the concept of virtual storage to the ['O components and providing the capacity of a 
tape library. Availability and mounting of the volumes was under the control of the 
operating system with the same variety of methods of data organization available on 
DASD. Even multi-volume data sets could be used. [Ref. 12, p. 41] 

The MSS records data on 2.7” wide by 55” long magnetic tape contained within cy- 
lindrical cartridges, 3.5” long with a 1.9” diameter. Two of these cartridges are referenced 
as one 3330V (V for virtual) volume and hold 100 megabytes of data, in the image of a 
1974-vintage 3330 Model 1 disk volume. The MSS consists of a Mass Storage Facility 
with Data Recording Devices, Data Recording Controls, and Mass Storage Controls 
with Accessors which take the cartridges from the honeycombed storage walls to the 
Data Recording Devices, returning them when finished. There are several possible 


configurations of the system. These vary from a minimum capacity of 35 gigabytes of 


data (equal to 350 3330-1 volumes) to 472 gigabytes (equal to 4,720 3330-1 volumes) in 
the maximum configuration. [Ref. 13] The NPS system was a model A02 with four Data 
Recording Devices, two Data Recording Controls, one Mass Storage Control, with a 
capacity of 2,044 data cartridges which equates to 1,017 virtual volumes with a capacity 
of 101.7 gigabytes. (Ten cartridge cells were reserved for operational considerations and 
maintenance.) 

On the MSS, data is staged from the IBM 3851, onto real IBM 3330 or 3350 disk 
storage in eight cylinder segments for as long as it is needed. (See Figure 2) Then, the 
data 1s de-staged, and the physical DASD can be used for eight more cylinders of user 
data. When the data is staged, it can be shared by more than one MVS job, as can any 
regular DASD data set. MSS can also be used for the VM user mini-disks. In June 
1987, the Center's MSS had 75 volumes for online, time-sharing users of VM, CMS and 
314 volumes for batch processing under MYS SP. 

Mass storage volumes are defined in groups with a name and an owner. After the 
group 1s defined, more volumes mav be defined to the group as desired. The Center's 
groups were primarily bv department, with some departments having multiple groups. 
With the MSS-provided ability to assign mass storage volumes to groups. the storage 
manager had some control over the use of the volumes. Since the inventorv data set 
group record contained the information for the group, allocation parameters could be 
specified for blocksizes and space allocations for data sets. Individuals did not have to 
specify their DASD requirements. The default parameters were used, whether or not 
they were optimum. [Ref. 12, p. 5] IBM recommended using naming conventions for 
improving control of application data sets and as future guidance to application pro- 
grammers. [Ref. 12, p. 41] NPS users generally used the defined naming convention but 
did not always follow the recommendation to catalog all data sets. If the user did not 
follow the naming convention, his data set could not be cataloged. Cataloging finally 
became accepted by all users one year after they were told that it was required. 

The concept of volume ownership by a user group dates back to the days of re- 
movable DASD. Asa physical security measure, the volume could be removed from the 
Computer Center and stored elsewhere. To maintain reliability with today’s technology, 
at such high access rates, DASD cannot be removable. With the capacity of DASD in 
the 1980's, it is extremely costly for a particular group to own its own volume. The 
largest IBM removable volume, IBM 3330-11, which the MSS simulates, holds 200 
megabytes. A double density IBM 3380 Model E holds 2.5 gigabytes, equivalent to 
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Figure 2. Mass Storage System Configuration 


twelve IBM 3330-11’s. New methods of management and control must be established 
in this environment. [Ref. 6] 

With an average access time, after staging, comparable to IBM 3350 disks, and a 
data transfer rate of 806,000 bytes per second, the MSS cannot begin to keep up with 
modern processors. [Ref. 14] Fhe speed of processors has increased significantly in 
thirteen years, but the Mass Storage Controller (MSC) processing speed of 30 to 45 or- 


ders per minute has remained fairly constant. Currently one CPU can send orders to the 


MSC faster than the MSC is able to process them. "When most installations were run- 
ning processors of the 370,145 to 370/168 class, the MSC could handle requests and 
commands from multiple CPUs." [Ref. 11] The 308X and 309X classes of processors 
easily exceed the MSC order rates. Processors running jobs that require MSS data will 
be severely limited by the 3850 speed. 

DASD and control unit speeds have also increased significantly. DASD transfer 
rates over 3 megabytes per second have become a requirement to keep today's CPU 
running efficiently. As with the MSC, the 3830-3 Staging Adapter (SA) and the staging 
DASD continue to transfer data at the nominal rate of about 800 kilobytes per second. 
As demands increase, the effective data rate of the SA's 1s reduced. 

Many computing faciliues installed the MSS as a low-cost storage device. At the 
time, it was a good choice of storage media for large quantiues of infrequentlv-used data. 
Although large and inexpensive, this seemingly infinite, virtual DASD had hidden costs. 
To keep the 3850 Subsystem running properly, the facility required. trained. systems 
programmers to install, maintain, and support it.. Manv installations required a person 
to spend full-time on the MSS--learning the product; managing data spaces; and recov- 
ering from component, volume, and subsystem failures. This expertise came from 
working on the Subsystem, and from IBM classes and workshops. As MSS reliability 
improved with resultant fewer outages, the recovery skills of systems programmers were 
exercised less frequently. When problems occurred, this made MSS recovery a longer 
and generally more difficult process. Users compounded this problem by storing many 
production data sets on the MSS. Occasionally, when the MSS would not be available 
and users needed this data, they would have to wait for the systems programmer to 
complete the problem determination and recovery. During these times, little productive 
work was done in the installation, and the MSS outage was extremely visible. This 
predicament could be avoided by migrating MSS data to DASD and tape, and keeping 
the MSS out of the critical path of the installation’s production jobs. [Ref. 11] 

Besides the emergency need for the systems programmer to identify problems and 
recover from them, much time was needed on a continuing basis. The Mass Storage 
inventory and journal data sets required backup and attention from the systems pro- 
grammer. A duplicate set of the MSS tables must always be available in case of failure 
of the primary tables. [Ref. 12, p. 5] Switching tables and recovery from table failure 1s 
not a trivial matter as was learned more than once. In April 1987, the Center experi- 


enced a recurring failure and a system outage of approximately eight hours on one day. 
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Where the MSS was the best solution in 1976, with faster processors and other 1 O 
devices, the MSS will not be able to satisfy users who need a large amount of storage 
at a reasonable cost, online to multiple fast processors in the 1990's. With IBM's an- 
nouncement of withdrawal of support of MSS on future systems, MSS users had to be- 
gin migrating Mass Storage Subsystem data to other storage devices. 

The report, 3850 Mass Storage Subsystem Migration Planning (GG66-0208-0), pub- 
lished in August 1985 [Ref. 11] described several migration strategies which could be 
used to replace an MSS in an orderly manner. This document does not discuss evalu- 
ation of whether to replace the MSS or not, but offers several approaches for the task. 
In 1985, some installations were quite content with their use of the MSS. If thev had 
developed the needed recovery skills and were pleased with their use of the MSS, they 
might see no reason to change the way they store and use the data in the MSS. If it 
was satisfactory for their application, they wanted to know why thev should migrate to 
something new. Until the 3090 announcement, this attitude was understandable. 

In February 1985, part of the IBM announcement package for the 3090 processor 
was a letter stating that IBM did not intend to support the attachment of an MSS to 
anv IBM processor beyond the 3090 Processor Complex. [Ref. 1] Even for the satisfied 
user, IBM recommended consideration of alternatives to MSS. The results of this review 
should be a plan to replace the MSS with DASD and tape that would connect to any 
family of processors. NPS must be prepared for further developments and make transi- 
tions and new purchases in an incremental fashion to lower costs and the impact of 
radical changes to the users of the NPS Computer Center. 

Over the last ten years the cost, floor space, and data density of DASD have made 
this type of storage more competitive with MSS. A combination of 3380E DASD and 
3480 tapes can provide an excellent alternative to the MSS Subsystem. They provide the 
solution to both the recovery skills problem and the MSC transfer rate problem. [Ref. 
11] They represent current technology and allow for growth to future developments. 

IBM recommended that the first step to knowing what to do about the MSS is an 
analvsis of its use. Classifying the data would tell vou what should be done. “You can't 
decide where to go without knowing where you are.” [Ref. 11] The three categories 
suggested by IBM are active, inactive, and a combination of the two. Inactive 1s defined 
as data that 1s either system managed or a copy of user data, created by a storage man- 
agement product such as IBM's Data Facility Hierarchical Storage Manager (DFHSM) 
or Data Facility Data Set Services (DFDSS). This data would not be directly accessed 


by an end user, if at all. In 1985, a number of users with DFHSM installed used the 
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MSS for Migration Level 2 (ML2) storage. IBM defined active data as data that is ac- 
essed directly by the end user, either in a test or production environment. Data in this 


` 


category would be referenced quite frequently, with, perhaps, some production job de- 


uv 


pendencies. Files belonging to staff and faculty members that have not been used in a 
long time (mavbe vears) are inactive, although the owners would want the files easily 
addressable by an MWS job stream. 1BM's recommendauon [Ref. 11J was to migrate 
all active data to something other than the MSS. At that point, how long the MSS was 
used in the Center would be up to the customer. This migration would take time and 
there could be a few interim steps and hardware configurations planned before the final 
data storage configuration ts achieved. The options recommended were to move all 
data. move only the active data and wait until the rest of the data was obsolete. or if it 
contained onlv inactive data, wait unul it was obsolete. then remove the MSS. Each 
option included changes in hardware and software. The configurations recommended 
by IBM included 3480 tape and 3380 disk hardware, and DFHSM as a storage manager. 
In most 3850 installations. a large percentage of the workload depends on the MSS 
being continuously available. Anv MSS outage caused missed deadlines and delays to 
many users. For the NPS. an outage affected nearly every user, with the individuel ec- 
counts (VM mun-disks) on MSS and the MSS an integral component to MVS. The 
Reliability -Avaiability-Serviceabilitvy (RAS) design and significant performance advan- 
tage of 3380 DASD are superior to that of MSS and its components. Under MISS. wien 
the stage-destase rate of approximately 123 kilobvies per second, 2 User mus Wai al 
least two seconds after the virtual volume has been mounted for @ Gata set to be opened. 
lf the data set 15 le evlinders or more, the user must wait siieea seconds. A maximum 
of four processors can connect to an MSS, but anv one processor can attach to only one 


iton. only three processors can be connected to anv Staging Adaptor. or 
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MSS. In 2d 
Staging Adaptor pair using 3 redundant path. [Ret A With 3350 DASD. gel: 
processors can be connected to any des a an alternate path. Ine 3480 tipe sub 
svstem, the A22 control unit pair can have tour CPUs connected, each with an alomat 
path. Although connectivity was not a —— for NPS. it would have & sienilithrk 
beanng in a large MSS installation, such as an insurance toinpany wih many Wears Gi 
data on the MS5. Upgrading to a new version of the eperatingz svstem or to & new 
processor family would be inhibited by the MSS. 

In IBM s 3850 Mass Storage Subsystem Mieration Planning, [Ret. 11]. tive contig- 
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manager, such as DIF HSM. Although not a necessity, IBM recommends installing it, 
as 1t would provide an automated storage manager to replace much manual effort. The 
benefits derived. from its use are both immediate and long-term and are discussed in 
Chapter IV. 


The first three configurations recommended bv IBM are 


l. All active data moved to 3380 DASD, inactive data moved to a combination of 
3380 DASD and 3480 tape. A storage hierarchy of 3380 DASD and 3480 tape 
with all active data moved to DASD onlv, DASD for DFIISM Migration Level 1 
(MLI) storage, and tape for DFIISM Migration Level 2 (ML2) and backup stor- 
age. 


2. Active data and inactive data moved to a combination of 3380 DASD and 3480 
tape. A variation of the first configuration, but assumes that the movement of 
some of the active data to 3380 DASD is not justified, due to the size or frequency 
of access. A storage hierarchy of 3380 DASD and 3480 tape with all active small 
and intermediate files moved to DASD, large files moved to tape, DASD for 
DFHSM ML I storage, and tape for DFHSM ML 2 and backup storage. 


3. No storage management product implemented, and the data currently residing in 
the MSS (both active and inactive) moved to a combination of 3380 DASD and 
3480 tape. Management of all devices done manually. In some cases, it would be 
necessary to replace storage management functions currentlv being performed by 
er Szutliviesesuch as SC RMSE sor Moot functions such as System Inıtlateg 
Scratch. There are no equivalent IBM alternatives other than DFHSM. A storage 
hierarchy. of 3380 DASD and 3480 tape with all active small and intermediate files 
moved to DASD, large files moved to tape, and with no storage management 
product installed. [Ref. 11] 


The other two configurations contained MSS as an interim configuration, only. 
Basically they are the same as those above, but the inactive data is left on MSS until it 
is obsolete. The objective of the migration is removal of the MSS. 

In order to estimate the new DASD requirements, a study was done of the MSS 
volume assignments and utilization. Space analysis was performed to determine what 
percentage of the MSS volumes were actually used in order to determine the amount of 
new hardware needed. The results are included as Appendix A. The use of 3480 tape 
drives and DFHSM for compaction reduces the floorspace necessary for more 3380 
DASD. 

The new releases of DFDSS and DFHSM which were provided on the Custom- 
Built Installation Package (CBIPO) provide the means to move the data easily and 
manage it effectively in the new environment. In order to use these products effectively, 
the data sets to be migrated had to be cataloged in Integrated Catalog Facility (ICF) 
catalogs. With this requirement as a prerequisite for subsequent steps, the beginning 


of the migration at NPS was the catalog conversion since the primary user catalog was 


of the old style control volume (CVOL) catalog. Chapter V will describe the specific 


steps in the migration process. 


IV. STORAGE MANAGEMENT NEEDS—HOW DFHSM SATISFIES 
THEM 


In order to understand what is needed in a storage manager for DASD, one must 
first understand the tasks to be done. Storage management tasks fall into three catego- 
ries: device, space, and data management. Device installation and maintenance are 
Boversd sullicientliy by Device Support Facilities, ICKDSF, an IBM utility, used by 
Computer Center's systems programmers. Management tasks are primarilv space and 


data set management. 


A. SPACE 

Space 1s allocated for data sets and released when data sets are deleted. This re- 
quires some control to ensure data sets are allocated to proper volumes and deleted 
when no longer needed. Sufficient space for allocating new data sets and extension of 
existing ones is critical. To ensure this, space must be used efficiently and effectively. 
If unblocked, SO byte records use less than 15% of a 3380 track. Full track blocking 
provides for maximum use of DASD capacity. Since there 1s no way at present to have 
default block sizes, the user must specify them. Optimum block sizes depend upon the 
track capacity of the specific device. If data sets are to be moved from one device to 
another, standards should be developed which effectively utilize the capacity for the 
types of devices used. Although, a block size of 19069 uses 100% of an IBM 3350 track, 
1t uses only 80% of an IBM 3380 track. [For data sets which are stored only on an IBM 
3380 (or 3380-image) device, a block size of 23,476 (half track) 1s optimal, allowing space 
utilization of 98.9%. [Ref. 15 p.146] For data sets to be moved between IBM 3350 and 
IBM 3380 units, a block size of 9076 uses 95% of botl units. [Ref. 6] 

Allocation of space by cvlinder was the default for user data sets on the MSS. 
However, this wastes space on an IBM 3380. The documentation given to the users for 
the migration of data sets from the MSS to IBM 3380s stressed allocating in blocks, not 
cylinders. This was something new so it required some learning on the part of most us- 
ers. Allocation in blocks assures good capacity utilization regardless of device type. 
Cataloging and eliminating the use of job or step catalogs reduces the chance of having 
duplicate data sets in the system. 

For the actual space on the volumes, Data Facility Hierarchical Storage Manager 


(DFHSM ) is irreplaceable as an aid in the areas of relocation (migration and recall), 


ES 


conversion, movement, retirement or archiving, and deletion. This is the product re- 
commended by IBM for the migration from MSS. [Ref. 11] It controls the amount of 
data on a volume, deletes obsolete data by age, creates backup copies, compresses data 
sets and moves them off the primary volumes, making room for more currently used data 
sets. When a volume becomes highly fragmented, the storage administrator can use 
DFDSS, an IBM utility, to rearrange the data sets to make available larger contiguous 
Spaces for re-allocation. Reorganization of the free space on a volume does not make 
more space. This brings us to the discussion of the data sets themselves. 

To manage the available space, there must be system-wide procedures for migration 
of data sets from the high availability DASD. DFHSM supports a hierarchy of levels 
of access. Primary volumes contain data for current use. The Center allocated ten 3380 
volumes as primary volumes (12.6 gigabytes). In order to have space for new allo- 
cations, space management runs daily with parameters specified to migrate any data set 
from a primary volume over 6025 full to a Migration Level 1 (ML1) volume in a com- 
pacted form if it has not been used in ten days. The Center allocated three 3380 volumes 
for MLI (3.78 gigabytes). From ML] volumes, data sets not used in 25 days will be 
migrated to Migration 2 (ML2) volumes. Three times, the MLI volumes have filled up 
completely causing migration to ML2 volumes. Until the ML] volumes fill to 80%, all 
of the data sets, no matter how old, are available to the users with no operator inter- 
vention. This has given availability of data on MLI volumes for three months or longer. 
Two hundred 3480 tapes were acquired to be ML2 volumes. After 14 months, 76 ML2 
tapes are between 50% and 99% full. Removing unused data sets, which migration 
does, 1s automated under DFHSM. Without DFHSM, the storage administrator would 


need to do this task. 


B. DATA MANAGEMENT 

The many areas of data management range from the creation to the deletion of data: 
creation and classification; control as related to identification and location, access (au- 
thorization, availability, performance), monitoring usage, standards; relocation as in 
migration and recall, conversion, and movement; retirement or archiving; and deletion. 
Naming conventions and aliases aid in control and classification, identification and lo- 
cation. 

Who is responsible for what tasks in the management of data sets? Ideally, the ap- 
plication users should be responsible for logical data, the system should be responsible 


for physical storage, with the storage administration group serving as a policy/control 


interface between them. [Ref. 6] In an ideal environment, the application users should 
only have to be concerned about the logical view of their files. This means that tasks 
such as backup, recovery, space availability, and volume clean-up are the responsibility 
of someone else. In the environment of personally-owned volumes, the user was re- 
sponsible for these tasks. For the system to be responsible for physical storage, there 
must be some interface between the system and the users. An IBM speaker at SHARE 
called this the Storage Administration group. “Studies conducted in 1982 and 1983 ın- 
dicate that 1t took one person for every ten gigabytes of DASD to perform the storage 
management tasks. At the average compound growth rate of 45%, even the smaller in- 
stallations, ... will require a large number of people just to perform the DASD manage- 
ment tasks.” [Ref. 6] In addition to being the interface between the application users and 
the system, this group would be responsible for all areas of DASD management such 
as policy definition and control; device selection, installation, and usage, space allo- 
cation, capacity utilization, capacity planning, service level management, installation 
standards, performance, availability. Additional tools and techniques need to be devel- 
oped and used that allow a storage administrator to manage large quantities of DASD 
(100-300 gigabytes). With a compound growth rate of 30-45 percent, new hardware 1s 
always part of the solution to storage management problems, but tools which automate 
as many of the storage management tasks as possible are needed to minimize the per- 
sonnel requirement of storage administration. Standards, especially data set naming 
standards, affect the ability of storage administration to automate the management tasks 
via software and standard procedures. 

The need for additional DASD capacity 1s always present. However, there 1s a point 
at which additional DASD capacity may not solve the storage management problem. 
For further information regarding the balanced system concept, the reader could refer 
to Capacity Planning, Basic Hand Analysis by L. Bronner, IBM publication number 
GG22-9344, or Balanced Systems and Capacity Planning by R. J. Wicks, IBM publica- 
tion number GG22-9299-01. 


C. SUMMARY 


In Chapter Il, it was stated that a mass storage system should provide: 
e Relatively fast access 
e Data access compatible with systems software and access methods 
e System accessible storage media 


e Technologies which can be enhanced to provide long-term storage solutions 


e Cost effectiveness not only based on price but on operational and environmental 
measures. [Ref. 2] 


With DFHSM, access for a data set used within the last seven days 1s at the rate 
of 3 megabytes per second, as fast as access to any data set on a 3380. If the data set 
has been migrated to MLI and, therefore, compacted, it must be decompacted when 
being moved from one 3380 to another. Although we don't know the rate of decom- 
paction, the amount of time is negligible. If the data set hasn't been used for a long time 
and has been migrated to ML2, it takes longer to retrieve, since operator intervention 
Is required to mount the correct IBM 3480 tape. From that point, the system operates 
at the speed of the high-speed tape and the high-speed DASD, viz., 3 megabytes per 
second. After recall from either ML] or ML2, it will remain on the 3380 as long as the 
user accesses the data set at least once a week. 

DFHSM uses standard IBM utilities to do the functions 1t requires. When these 
utilities are improved, the improvements will be automatically a part of DFHSM. Along 
with using the latest in software, the hardware which can be used is IBM’s latest. 
DFHSM has been announced as a strategic component of IBM's MVS ESA (Enterprise 
Svstem Architecture). That makes it clear that support for new hardware and software 
will be a part of DFHSM. Currently it supports the following devices: 3330 direct ac- 
cess storage devices, models 1 and 11; 3350 direct access storage devices; ISTMO 
access storage devices; 3380 direct access storage devices, models A04, 804, AA4, ADJ, 
BD4, AE43, BEY and all the J and K models; 3850 mass storage svstem; 3420 magnetic 
tape units; 3430 magnetic tape units; and 3480 magnetic tape subsystem. With this 
support and the MVS ESA announcement with DFHSM as a strategic component, the 


questions of compatible media and long term support are satisfied. 


V. IMPLEMENTATION 


A. CATALOG CONVERSION 

Implementing the DFHSM program required that all of the catalogs be Integrated 
Catalog Facility (ICF) VSAM catalogs. The catalogs were old style VSAM, with the 
user catalog the older style control volume (CVOL) form. The first step in the DASD 
migration process required converting all the MVS catalogs to ICF VSAM catalogs. 
The system master catalog conversion was first and it went smoothly. Each user catalog 
has an entry in the master catalog. Along with references to the user catalogs, the 
master catalog contains “aliases” which refer to the high level index, or first segment, of 
the data set name. An alias points to the user catalog where a data set with that high 
level index will be cataloged. The use of aliases helps enforce the use of some naming 
conventions. [Ref. 16] The master catalog is password protected while the user catalogs 
are not. If the user follows the established naming convention, the data set can be cat- 
aloged in the proper catalog. Otherwise, the svstem will try to catalog it in the master 
catalog. The operator cannot give the password, therefore the data set will not be cat- 
aloged if the established naming conventions have not been followed. When the data 
set 1s not cataloged. DF HSM indicates this fact on its daily space management report. 
Eleven days after creation, the data set will be deleted. The naming convention in effect 
at NPS is a simple one. The first segment correlates a defined alias to the catalog in 
which the data set is to be cataloged. It must be correct in order for the data set to be 
cataloged. For the basic user, the second segment contains a code of an alpha character 
indicating the user category (student, faculty, computer center staff, and others), fol- 
lowed by the user number, thereby identifying the owner of the file. Some other special 
users have their own first level index to put files in separate catalogs. For them, the 
second segment has specific identifiers to establish ownership of the data set. 

The IBM conversion utihty failed on the second catalog, the catalog for a strategic 
School function. After restoring the VSAM files for the third time from the backup, 
normal recovery procedures were considered. There was no ongoing procedure for a 
frequent, regular backup of these strategic VSAM files. This vulnerability was corrected 
by instituting a weekly backup of these files in order to recover from future failures. 
IBM's support was requested on the conversion of the second catalog. They sent doc- 


umentation of a new function of the IDCAMS utility, DIAGNOSE, which analvzes a 
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VSAM catalog for errors and should be used prior to conversion. IBM felt that errors 
in the catalog had caused the conversion utility to fail. This hypothesis could not be 
confirmed because our restoration of the catalog could have caused the incongruencies 
that existed at that point. This DIAGNOSE function was run against the remaining 
VSAM catalogs prior to conversion. None had errors. Since the conversion utility 
would not work on the second catalog, each data set had to be EXPORTed (copied) to 
a sequential file for backup, deleted, allocated in the new catalog, then IMPORTed 
(copied) from the sequential file. This was a much more time-consuming process than 
experienced when using the IBM utility provided for the conversion process. 

The catalog in which all the user data sets were recorded was of the older stvle 
CVOL catalog. It was converted to an ICF VSAM catalog during the last week of De- 
cember 1987 with no problems. The major difference to the users, between the old style 
catalog and the new one, was the deletion of an outdated utilitv (IELIPROGM ) which 
did not reference the catalog. The users were notified of this fact several weeks prior to 
the conversion of this catalog. The old utility was no longer required. Another utility 
(IDCAMS) did the same functions but the users did not want to change JCL that 
worked...or JCL they thought worked. (After the conversion, 1100 entries ٦ 
from this catalog for data sets supposedly deleted by using the old utility. However, the 
old utility did not delete the entry from the catalog. It merely scratched the data set.) 
This was the beginning of the visible reluctance of the users to accept the changes that 
were to come. Along with the requirement to use the IDCAMS utilitv instead of the 
[EHPROGM utility, the Computer Center published an article containing detailed in- 
structions and JCL for use when cataloging data sets. After the data set was created, 
the user need only refer to it later with the DATASETNAME (DSN) and DISPOSI- 
TION (DISP) parameters. Using the data set entry in the catalog was the first step for 
an easier transition for later changes. Many users ignored this recommendation. 

According to IBM, [Ref. 11] probably the most difficult part of the MSS migration 
will be the JCL modification necessary to direct all new allocations away from the MSS. 
There are no IBM products available to perform the changes. Except for procedures 
such as the FORTRAN compiler procedures, etc., it was recommended that all JCL just 
reference the cataloged data sets with only DSN and DISP parameters on the data de- 
fimtion (DD) statements. For allocation, the generic UNIT=SYSDA replaces 
UNIT 7 3380 and a specific VOL = SER = nnnnnn from the pool of volumes. 

Instalhng the hardware, the additional 3380s and controllers and the 3480 tape 


drives, was the next step. The hardware installation was originally scheduled for the 


spring break, a long weekend between quarters at the end of March. The lack of courses 
with accompanying assignments for the students during this short period would have 
allowed the Computer Center the luxury of having the computer completely down for a 
few days. Unfortunately, this schedule could not be met because of procurement delavs. 

If the hardware had been installed at the end of March, the Custom-Built Installa- 
uon Package Offering (CBIPO) for MVS with DFHSM could have been installed four 
or five weeks earlier. DFHSM then could have been used gradually on groups of files, 
beginning with the ones belonging to the Computer Center staff. This scenario would 
have allowed the writing of the “cookbook” technical newsletters and procedure files to 
aid the users in handling their data sets. 1f the Computer Center staff had been able to 
use the product for a short while, most of the problems which we experienced might not 
have occurred. A gradual changeover would have made for a smoother migration. 
Though some users resisted, the changes would have been more transparent had the 
entire Center's staff been more able to help. The primary differences concerned allo- 
cating new files with block instead of cylinder allocation and using the IDCA MS utili- 
tics. It seemed that some of the Computer Center staff objected to the change as well 


as the less experienced users. 


B. USER DATASET EVALUATION AND BACKUP 

Some users wanted to backup their data from the Mass Storage Subsystem (MSS) 
prior to the migration. Defense Manpower Data Center (DMDC) moved some of their 
data from the MSS to DASD owned by them. Generally, DMDC data residing on the 
MSS was of a backup, archival nature. Therefore, most data was moved to tape. The 
initial attempts at producing these backups were not very successful. DMDC's Full- 
Virtual- Volume-to-tape jobs (using DFDSS, an IBM utility for dump, restore, or copy 
operations) required six to eight hours for one MSS volume. Investigation revealed that 
MSS was staging the data sets eight cylinders at a time! To overcome this problem, 
Mr. D. Norman, Manager of the Systems Support Group for the Center, wrote a small 
assembler language program which accessed the MSS Communicator at the SVC level, 
mounted and staged a complete volume, then invoked the DFDSS copy program. The 
program then released the MSS volume. Done this way, the backup process was re- 
duced to 10 to 30 minutes per volume. 

The identification of obsolete, deletable data was left to the user. Many phone calls 
were made to the owner of each MSVGP group. The owner, alone, knew the value of 


the data sets on the virtual volumes. It was assumed that each owner had done the 
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requested evaluation by the specified deadline. If the data sets were not cataloged, as 
required, it was assumed that the user did not want the data set. Every cataloged data 
set on each MSS volume that the owner did not personally delete or ask us to delete was 
migrated. The users, if available, were contacted for confirmation that they did not want 
each uncataloged data set. Very few of these were subsequently cataloged and moved. 

According to IBM, "the migration from the MSS is not going to be without some 
cost. The Space Manager is going to have to do the majority of the work, but the co- 
operation of the end-users will be important to the success of the migration because they 
will have to do some of the work. Even if the majority of the JCL changes, data de- 
letion, and data movement can be done by a Production Control group, a Storage 
Manager, or a combination of the two, there will be a required participation by the 
end-user community. JCL that exists in individual data sets must be changed, obsolete 
data sets must be identified, and some of the data movement will have to be done by the 
end-users. It will be useful to gain the support of the end-user community earlv in the 
planning cycle so that they are aware of the work that must be done.” [Ref. 11] 

Upon request, Center users Were assisted in creating their own backup copies of 
their data sets prior to the migration. Earlier backups from 3850 would not be able to 
be restored once that hardware was removed. Some users fought the changes, although 


the changes were few in number. Generally, JCL was simplified in the process. 


C. SOFTWARE INSTALLATION 

The Custom-Built Installation Package Offering (CBIPO) for MVS was installed 
during May 1987 after the installation of the 3380s and 3480s. This task required about 
four weeks of full-time effort bv a senior systems programmer. This CBIPO contained 
the base MVS operating system wıth no major svstems changes, except the addition of 
DFHSM. New releases of several utilities were included which were needed to support 
DFHSM and upgrade the system components to current levels. A CBIPO with more 


new functions and changes would have taken even longer to install. 


D. MIGRATION 

The VM mini-disks were moved from MSS to 3380's over Memorial Day, May 1987. 
The VM Systems Programmer did all of the copying, making the change virtually 
transparent to the users. 

The procedures for implementation of DFHSM were set up and the migration be- 
gun. Volumes of the Mass Storage Subsystem (MSS) were migrated to DFHSM Mi- 


gration Level 2 (ML2) volumes on 3480 tapes. The initial migration was begun on a 
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Sunday, June 21. Recall was tested on various types of data sets from different ML2 
tapes. Each task worked perfectly. As we attempted to recall data sets on the loaded 
system during the following workdays, we found that the tape drives were never allo- 
cated to DFHSM for the recall of the needed data sets. After much research and many 
phone calls, IBM responded with an “undocumented” parameter which makes it possible 
to define the DFHSM 3480 tape drives as a different unit from the other 3480 tapes 
drives. The migration continued, with the majority of the data sets being moved over 
Me Fourth of July weekend. 

In recalling migrated data sets, we ran into two categories of data sets that caused 
problems: (1) direct access data sets (created by FORTRAN programs) and (2) data sets 
which could not be reblocked upon recall. The direct access data sets created by SAS 
programs had been moved prior to the migration. (SAS is a Statistical Analysis System 
from the SAS Institute, Cary, North Carolina.) A Center staffer consulted with another 
university Which had been using DFHSM for several years and inquired about the effects 
upon SAS data sets. The reply was that DFHSM handles the data sets created by SAS 
as long as they are migrated from, and recalled to, the same type of unit. This would 
not be true during our migration, from the 3850 with its virtual 3330 volumes to the real 
3380 volumes. A known procedure was used to move SAS data sets to 5380s prior to 
the actual migration. There were about 1,500 other direct access data sets on the system. 
The IBM documentation states that DFHSM will handle direct access data sets prop- 
erly. [Ref. 17] After discussions with IBM personnel, we assumed that our direct mi- 
gration would work. In fact these direct access data sets were handled in the same way 
the SAS data sets were, that 1s, fine when migrated from, and recalled to, the same type 
unit. The migration proceeded. Afterwards, these direct access data sets all had to be 
recalled first to a 3350 volume simulating a 3330-1, then moved with DFDSS, a utility 
for copying data sets, to a 3380 disk prior to use and control by DFIISM. IBM assured 
us that future documentation would be clearer on this point. 

The second problem, data sets which could not be reblocked upon recall, was solved 
bv IBM. A parameter on the DFHSM control procedure was changed for one CPU 
from CONVERSION(REBLOCKTOANY) to NOCONVERSION. If the job calling 
for the data set failed when running on SY2 (the 3033U CPU), the user could contact a 
Computer Center staff member with TSO access. TSO runs on SY3 (the 4381 CPU) 
where DFIISM was set up with the NOCONVERSION parameter. Or, the user could 
resubmit the job, specifying that it should run on SY3. This problem only occurred on 


the first recall of the data set after migration from the MSS. 


From the first of July 1987 until the first of September 1987, no other problems were 
encountered. In early September, two unusual partitioned data sets (unformatted) could 
not be reealled from the DE1ISM ML2 tape. Other data sets created the same way had 
been recalled. The IBM Support Center defined the problem as a missing end-of-file- 
marker on the members (or a member) in each of these two partitioned data sets pre- 
vented reeall. IBM aecepted this problem from us and a few other users to make an 
immediate code change for DFHSM. It will no longer allow data sets such as these to 
be migrated or baeked up in the first place, and will give an error indicating that these 
data sets are not standard and not covered by DFHSM.! Luckily, the owner of the two 
data sets, a doctoral candidate, was able to reereate them. 

In mid-September, a DFHSM ML2 tape would not allow the recall of any of the 
data sets on it. The label had been damaged by an operator re-labeling it after DFHSM 
had written files on the tape. A program was written to eopy the DFHSM tape to a new 
tape, a record at a time. Only the first file was lost from the tape. The procedure was 


doeumented and the program was saved for similar future recoverv situations. 


E. ONE YEAR LATER 

After monitoring DFHSM for a year, observing the storage management function- 
ing well, the Center is quite pleased with DFHSM and all the storage control it affords. 
There may be some tuning which still needs to be done, but not as much as was imag- 
ined when the project was begun. The original estimates of how much space should be 
allocated to each level appears to be still appropriate. On August 22, 1988, one primarv 
volume was removed from DFHSM's control in order to use it for another purpose. 
This caused the other volumes to fill. One migration parameter, how long data sets 
would be allowed to stay on the primary volume since the last reference, was lowered 
from ten to six days. After approximately two weeks, with much forced migration by 
the author, 1t appears that DEFEHSM has evened out the load. 

At first glance, the migration would seem to be a step baekwards: from an auto- 
mated mass storage system entirely under system control to one with operator inter- 
vention required at one level. However, the annual eost savings are substantial and 
considerably more space is available for the users. 

Managers of automated data processing installations have to stay in toueh with 


trends in technology. The changes that will eome with. IBM's. Enterprise System 
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Architecture (ESA) will be dramatic. The user's view of storage is changing from the 
physical to the logical. After a data set is created and cataloged, its physical location 
1s not important to the user. The system can move the data set around to maximize the 
use of the physical DASD. DFHSM does this. IBM has stated that DFHSM will be a 
strategic product in ESA. The Computer Center is now well-positioned for the future 
developments. 

A snapshot profile of storage utilization was taken on September 2, 1988, 8:41 a.m. 
At that time, 119 users had data sets on primary and Migration Level 1 storage. 
Table 2 shows how much space (in tracks) and what percentage of the total that the top 
ten percent of the users had allocated. It comes as no surprise that they used 76.5% of 
the allocated primary storage and 19.3% of the space used on MLI storage. The top 
user, a student in the Air-Ocean Curriculum approaching graduation in December, had 
49.5970 of the allocated primarv space. This is equal to nearly 20 old MSS volumes plus 
nearly two more for the data sets on MLI storage. He also had 155 more data sets on 
Migration Level 2 (ML2) on 3480 tape. Ile is using the files on primary storage on a 
continuing basis or they would be migrated. He and the second largest user, a doctoral 
candidate, each have 137 files allocated on primary and MLI storage. The second user 
has 187 more data sets on ML2 storage. Prior to the migration from the MSS to 
DFHSM, a user was limited in the amount of space and the number of data sets held 
on public storage. At this time, the Center has not defined limits to the amount of space 
a user can allocate. This policy will be reviewed periodically. 

Since user $2310 had so much space allocated, the author looked at the utilization 
levels. On some of his data sets, he was using only one-third of the allocated space. 
These are large data sets, therefore the amount wasted was considerable. Besides keep- 
ing an eye out for his data sets which could have excess space freed manually, the author 
counseled the user on his job control language. He was only too happy to add the RLSI: 
parameter to his space request to release any space not needed by the jobs that he was 
running. He was using job control language given him by another user and really had 
only a rudimentarv knowledge of what the job control language was doing and no idea 
what other options were available to him. 

The snapshot contains information which would be beneficial to the Computer 
Center as an aid in monitoring users. Because of this, the author wrote a program to 
obtain this information. It can be run as often as is necessary, but current plans are to 
run it monthly. The first run, approximately three weeks after the snapshot view, 


showed that user S2310's usage had dropped from 49.5% of primary storage to 38.6%. 


He is still using a large amount of storage, but there is 100% utilization of his data sets 
now. The first run of the program showed that the top 10% of the users were using 
77.19% of primary storage. Six of the users from the snapshot were still in the top 10% 
three weeks later. Two users on the snapshot (CC0O8 and C0037) belong to the Com- 
puter Center’s Accounting Office. The author’s program combines them into one user. 
Because the files used by the Accounting Office are used continuously, they will not be 
subject to migration, but will be moved to another volume not under control of 
DFHSM, when such space becomes available. The program also combines the infor- 
mation about other users with more than one user [D in order to have a more definitive 


description of system usage bv user. 


Table 2. TOP 12 USERS OF STORAGE 
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33,060 2 POSTS 
Users are in descending order by space allocated on primary volumes. 
Percentages are of the total allocated space for that category. 






The Center will continue to monitor the utilization of space to see if the correct 
amount is allocated to primary and MLI volumes and if two hundred 3480 tapes will 
handle the data for two years as in the original forecast. The parameter specifying how 
long data sets remain on primary storage has already been changed, but only after 14 


months. 
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The challenge will be to decide whether to limit the users and, if so, how. The above 
table shows that the users at the bottom of the table, with amounts of data on MLI! 
comparable with other users” primary storage, have not been working with those data 


sets for over a week. This indicates that DEHSM is doing what was intended. 


APPENDIX A. SPACE AND USAGE ANALYSES OF MSS VOLUMES 


The following data on the total space in user data sets were acquired at approxi- 
mately the same time of year (the second week in May); in 1986 and 1987, by a single 
run each with an IBM utility on the MSS and, in 1988, by listing all the data sets on the 
relevant 3380 disk and 3480 tape volumes. The data concern user data sets existing on 
MVS volumes on May 5, 1988 with MVS CPU usage during the academic quarter, 
January 4 through March 24, 1988, as reported by Duquesne’s Billing Database Facility 
(BDBF) accounting package. 


A. SPACE 


Summarv statistics are shown in Table 3. 


Table 3. COMPARISON OF THE USE OF MASS STORAGE—1986-1988 


86 p | m 
Volumes 2 

io | ossi 
Space Allocated A 
(Megabytes) 92152 20,480 17.752 

Space Used 54 

تک ا 
86% 










In 1986, 288 volumes contained 10,610 data sets with 19,152 megabytes allocated. 
Of that space, 13,123 megabytes were used. This is 69% of the space allocated. At that 
time, 66% of the available space was allocated and only 45% of the available space was 
used. 

In 1987, 314 volumes contained 10,651 data sets with 20,480 megabytes allocated. 
Of that space, 14,654 megabytes were used. This is 72% of the space allocated. At that 


time, 65% of the available space was allocated and only 47% of the available space was 


used. 


28 


In 1988, under DETISM, there were 6,754 data sets migrated on 3480 tape volumes 
and 1,564 data sets online on 3380 DASD for a total of 8,318. This ıs a 22% decrease 
in the number of data sets from 1987. This might be explained by the review and de- 
letion of obsolete data which took place prior to the migration off the MSS. There were 
10,777 megabytes in the data sets which were migrated and 4,499 megabytes in data sets 
online for a total of 15,276 megabytes in use, which is a 4% increase over 1987. Space 
used 1s 86% of the space allocated. Of the 6,975 megabytes allocated for online data 
sets, 64.5% was used. 

Table 4 shows the results of an evaluation conducted in the first week of May, 1986. 
This evaluation was not re-run in 1987. From Table 3, it would appear to be unneces- 
sary to re-run It because the data for 1987 were quite similar to 1986. This information 
was used as a starting point to determine how much space would be needed for primary 
volumes under DFHSM. This table shows that approximately 24% of the available 
space was referenced within 31 days. Only 15% of the available space was referenced 
within seven days. This implied an initial value of 6.99 gigabytes of space needed on 


primary volumes under DFHSM for data sets to be used in less than 31 days. 


Table 4. SPACE UTILIZATION BY DAYS SINCE LAST 
REFERENCED—MAY, 1986 


REFERENCED Used = Allocated 
ne xu کی‎ 
L9 poem 





Added to this space requirement was space needed for all the temporary data sets on the 
system. At the time this evaluation was made, there were six 3350 volumes (or 1.8 


gigabytes) dedicated to this purpose. Initially (June 1987), ten 3380 volumes were 


allocated as DFIISM primary volumes for a total of 12.6 gigabytes of space. By the end 
of July, three migration level | volumes (3.78 gigabytes) were added. Migration level 2 
is on 3480 tapes. Fourteen months after the migration from the MSS, seventy-six (76) 
3480 tapes are being used. Two hundred were estimated to be needed for saving data 
up to two years after last reference. This estimate still is reasonable. Fourteen months 
after the initial assignments, one 3380 volume has been removed from the primary vol- 
umes to free it for other use. This caused much interval migration to occur on the other 
primary volumes, initially. Interval migration occurs when a primary volume reaches 
80% of full capacity. DFHSM checks each volume, hourly, to see if interval migration 
is needed. The migration parameter of ten days since last reference on the primary vol- 
ume has been changed to six, and further modifications may be necessary. Evaluation 


will continue and changes will be made when the need arises. 


B. USAGE 

Table 5 shows the percentage of the total amount of space used in data sets of 
various sizes for each of the three years. In 1986 and 1987, most of the data sets were 
quite small because of the limits of the MSS. The 1988 data indicate a good distribution 
through the range of sizes. This shows that, after the migration, the user was able to 


decide the optimum size data set for the particular application. 


Table 5. PERCENTAGE OF DATA SETS OF VARIOUS SIZES FOR 1986 TO 
1988 
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Data set sizes are in 3380 tracks. 
Table entries are the percentages of allocated space. 
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In June 1988, a study was made of the use of disk storage by the large MVS users, 
1.e., those using more than 25 CPU hours during the winter quarter, January to March, 
1988. The results are presented below in a series of tables based on CPU utilization. 
In each case, the table entries are the total numbers of 3380 tracks occupied by the user's 
data sets of specified sizes. Only data sets labelled with the user's id number were 
counted. Users were not interviewed to determine if they used other data sets. A total 
of 17 users were involved in this study. 

In Table 6, student user $3242 (Air Ocean Sciences) used over 400 CPU hours on 
MVS for the first quarter 1988. He graduated in June 1988 and primarily used large files 
for his data sets. Faculty user, F3862 (Assistant Professor, Oceanography) used be- 
tween 301 and 400 CPU hours in the first quarter. She used a wider range of sizes but, 


also, primarily used large files. 


Table 6. DISTRIBUTION OF DATA SETS FOR USERS WITH OVER 300 CPU 
HOURS 


DATA SET SIZES 
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In Table 7, faculty users, 4073 (Visiting Professor, Meteorology) and E3922 (Ad- 
junct Professor, Physics) and student users, $3048 (June 1988 graduate) and $3085 
(September 1988 graduate) both in Air Ocean Sciences, used between 101 and 200 CPU 
hours in the first quarter. As can be seen in Tables 7 and 8, the amount of space and 


size of data sets varied greatly. 


Table 7. DISTRIBUTION OF DATA SETS FOR USERS WITH 101-200 CPU 
HOURS 


61-100 © 2,097 


101-150 8,707 
151-200 4,044 
Over 300 


Data set sizes EN user amounts are in 3380 tracks. 
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The users in Table 8 consumed between 51 and 100 CPU hours on MVS during the 
first quarter 1988: faculty users, F3902 (Meteorologist) and F1950 (Associate Professor, 


Mechanical Engineering) and student users, $4555 and S1709, both in Naval Engineer- 


ing. 


Table 8. DISTRIBUTION OF DATA SETS FOR USERS WITH 51-100 CPU 
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The users in Table 9 used 25-50 CPU hours. They ٣ 
(NAVSEA Professor, Meteorology), F3971, (Assistant Professor, Oceanography), 
F0455, (Professor, Physics), and F2074, (civilian staff, Meteorology), NPS staff user, 
N3958, (Program Manager, PERSEREC), and student users, $4550, (Naval Engineer- 
ing), and $3064, (Operational Oceanography), both June 1988 graduates. 


Table 9. DISTRIBUTION OF DATA SETS FOR USERS WITH 25-50 CPU 
HOURS 


DATA SET re 
SIZES | F3956 | S4550 | F3971 F2074 | S3064 
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APAR 


Cache 


CPU 
DASD 


DFDSS 


DFHSM 


GUIDE 

IBM 

IBM 370/145 

IBM 370/168 

IBM 2321 Data Cell 


IBMI 3084 
IBM 3090 
IBM 3350 DASD 


IBM 3380 DASD 


IBM 3480 


IBM 3850 
IBM 3880 


APPENDIX B. ACRONYMS 


Authorized Program Analysis Report of IBM program er- 
rors filed by users 


High-speed buffer storage that contains frequently accessed 
instructions and data, usually on solid-state components 


Central Processing Unit 


Direct access storage device, a device on which access time 
is effectively independent of the location of the data 


Data Facility Data Set Services, a DASD data and space 
management tool 


Data Facility Hierarchical Storage Manager, an IBM pro- 
gram product (number 5665-329) that uses space manage- 
ment, backup, and recovery to manage data sets on a 
hierarchy of storage devices 


IBM users” group for DOS operating systems 
International Business Machines 

CEE antiroduced ۵ؤ۵‎ 

CPU Introduced 1n 1972 


A direct access storage volume containing strips of tape on 
which data are stored [Ref. 18]. 


CPU ıntroduced ın 1982 
CPU introduced in 1985 


317.5 megabytes capacity with 1.198 megabvtes per second 
transfer rate, uses a sealed head disk assembly with 16 re- 
cording surfaces 


2.5 gigabyte capacity with an average seek time of 16 milhi- 
seconds and a data transfer rate of 3 megabytes per second; 
a film head technology is used to achieve writing and read- 
ing of data recorded at higher densities than previous disk 
storage devices 


Cartridge tape drive subsystem which consists of a buffered, 
microprocessor-controlled, control unit and two 
microprocessor-controlled, tape drives that use a cartridge- 
enclosed 18-track, high-density magnetic tape cartridge; 
data rate of 3.0 megabytes-per-second. 


Hardware for the Mass Storage Subsystem 


High-performance cached DASD subsystem; the model 11 
is used for paging and swapping and can be attached to a 


ICH 


JCL 
MLI 


M L2 


MSS 


MVS 
NPS 


Primary volume 


SHARE 
TSO 
VM 
VSAM 


1.5, 2.0, or 3.0 megabytes per second channel and to one 
string of two, four, six, or eight 3350 devices; the model 13 
Is designed for system and application data and can be at- 
tached to 3.0 megabytes per second data-streaming channels 
and 3380 DASD. 


Integrated Catalog Facility, offers significant advantages 
over, and designed as a functional replacement for, OS 
control volumes (CVOLs) and VSAM catalogs. 


Job control language used to identify a job to an operating 
system and to describe the job's requirements 


Migration Level I, category of volume to which DFIISM 
migrates data sets from primary volumes 


Migration Level 2, categorv of volume to which DFHSM 
migrates data sets from migration level 1 or primary vol- 
umes 


Mass Storage Subsystem, composed of an IBM 3850 and 
Supporting staging disks, IBM 3350s 


Multiple Virtual Storage; IBM batch operating system 
Naval Postgraduate School 


Categorv of DFIISM volume contaming data sets that are 
directly accessible to the users and managed bv DFHSM 


Users” group for users of large IBM systems 
Time Sharing Option for interactive use under MVS 
Virtual Machine (interactive operating system) 


Virtual Storage Access Method for indexed or sequential 
processing of fixed and variable-length records on direct ac- 
cess devices. Files may be organized in a logical sequence 
by means of a key field or a relative-record number. 


36 


LIST OF REFERENCES 


IBM Internal Use Only Memo of February 12, 1985, Information Systems Group, 
International Business Machines Corporation. “IBM 3090 Processor Complex” 


and “3850 Mass Storage System Information,” Rye Brook, New York: 1985. 


Moore, Fred, “Improvements in Architecture and Technology are Resulting in a 
New Storage Hierarchy,” Mainframe Journal, pp. 15-26, 64-65, Dallas, Texas, 
September-October 1987. 


International Business Machines Corporation, Introduction to IBM 3550 Storage 
Control Model 15, GA32-0062-1, 2nd Ed., IBM Corporation, 1983. 


٦۳۰۰۲۰۰۰٠٠٦ Siobena s. "Different Storage Technologies Meer Different Needs, 


Government Computer News, March 27, 1987. 


Information Systems Group, International Business Machines Corporation. IBM 
Product Announcement, “IBM 3990 Storage Control,” Rye Brook, New York: 
1987. 


Profit, L.A., "DASD Subsystem Management, SHARE 67 Proceedings, pp. 
480-492, Chicago, Illinois, August 1986. 


Goldstein, Stephen, “Storage Performance: An Eight Year Outlook,” IBM speaker 
at Computer Measurement Group meeting in San Francisco, California, September 


IS 


International Business Machines Corporation, Introduction to the IBM 3850 Mass 


Storage System ( MSS), 3rd Ed., IBM Corporation, 1975. 


International Business Machines Corporation, IBM 3380 Direct Access Storage: 
General Information, GC26-4193-2, 3rd Ed., p. 11, IBM Corporation, 1986. 


37 


EE 


IS. 


International Business Machines Corporation, IBM 3350 Direct Access Storage: 
Description Manual, GA26-16358-4, Sth Ed., p. 17, IBM Corporation, 1984. 


Malarkey, D. J., and Taylor, L. B., 3850 Mass Storage Subsystem Migration Plan- 
ning, GG66-0208-0,, Washington Systems Center, [BM Corporation, Gaithersburg, 
Maryland, 1985. 


International Business Machines Corporation, OS/VS Mass Storage System Ex- 
tensions Services: Guide, SH35-0035-1,, 2nd Ed., IBM Corporation, 1982. 


International Business Machines Corporation, Operators Library: IBM 3850 Mass 
Storage System ( MSS, Under OS; VS, GC35-0015-4, IBM Corporation, 1983. 


International Business Machines Corporation, Reference Manual for IBM 3850 
Storage Control Model 1 and IBM 3330 Disk Storage, GA26-1592-5, 6th Ed., IBM 
Corporation, 1976. 


International Business Machines Corporation, /BM 3380 Direct Access Storage: 
Planning and Use, GC26-4208-0, Ist Ed., p. 146, IBM Corporation, 1985. 


International Business Machines Corporation, MVS’ 370 Catalog Administration 
Guide, GC26-4053-1, 2nd Ed., p. 30, IBM Corporation, 1985. 


International Business Machines Corporation, Data Facility Ilierarchical Storage 
Manager Installation and Customization Guide, ST135-0084-1, 2nd Ed., p. 23, IBM 


Corporation, 1985. 


International Business Machines Corporation, Dictionary of Computing, 
SC20-1699-7, 8th Ed., IBM Corporation, 1987. 


38 


INITIAL DISTRIBUTION LIST 
No. Copies 


Defense Technical Information Center 2 
Cameron Station 
Alexandria, VA 22304-6145 


Librarv, Code 0142 2 
Naval Postgraduate School 
Monterey, CA 93943-5002 


Linda Mauck 2 
Code 0141 

Computer Center 

Navy Postgraduate School 

Monterey, CA 93943 


W.R.Church Computer Center 1 
Code 0141 

Navy Postgraduate School 

Monterey, CA 93943 


Commanding Officer 1 
Naval Regional Data Center 

Washington Navy Yard 

Washington, D. C. 20374-1662 


Technical Director 1 
Naval Data Automation Command 

Washington Navy Yard 

Washington, D. C. 20374-1662 


39 






















a teen eee ee Ma Y 

TOLERAR T‏ اھا ال 2 TR‏ ا 
A a ae D few Y A a bo ded T " g‏ نیہ moon‏ 5 

P Me even T peer HT Mn e ette Kerry Ade Spb bra c bi ce سس‎ 
add f VI nd CELL 


O a سے سے‎ PA 
AAA RIA T گا‎ As A did 
aeri t Pe pw ere Jar Heer Id enisi E reir Hes cir O "Mr Er f 
A f H : M # 










2 
سے سور‎ AA "a 

m = 7 A ee ENTER TEN EI E ay! A 7 
سو اہ سرب ہپ ا یر کر سو سس سر مت‎ U سر کک‎ ng d peer repo Pn ru Det ia ARA ra 
A EEG ar BAM rer Re Lern eb q bd e ae RAEI T : . ۱ 





re vna É A 
ee NT سا کس‎ arbre GP HIS 
pr... SID the M38 
rer peret RAT ele ANSIA a 
0 ام‎ ger NTRA CI ۷ 
ا از بن مھ‎ ARA 
PARA al eed mum ات یں‎ 


especie Te E arde 

AA A roo PE eid 
A PA ٢٣ تیج‎ 
ponen A Th alae! afta S. s 4. 

roy ere NS por lw A 


Pp وچ ہہ‎ 
CT LL جم نہ جا‎ 4 
تی سانش رر ری رر‎ PON UT 
eques rag orm m erue iem n re erm 
PP abo padia e ou^ t of Gata ام ہیں‎ 0 10%. > 
Sr Ten دسا سی‎ Y PROP D TS Les T6 vA ef, Fons E TO nea درف و‎ | | 
UA IA ا ا‎ 0 paí "E I O ^ | 
wem رش ھی یں‎ oo RA baka EA ری و‎ | IIT: 
pier A و ا‎ IE 52 pS TT da PU LT pe ey ee T A | | | 
ےو سی‎ RA A AR pana tro” rt is N A ‫٠ سن‎ $ A "ege 
dece ose iere ver O ہی ہر وس ہو‎ Tree hae mu le LY ہا‎ pee: | 
Pa I SI ER iii PA A 4ھ ملي کے ا اع‎ PA A ا کا‎ PO SL Per رو‎ 
مث ا اس ال ود بے‎ dere ET سا ا‎ ED eI ER ۱٦ | 
parare ret ire A dad e een te Pen m s M tenw یں‎ a seep | | 
; P IA ۲ ate لین انتا‎ 1 e P TT 44A en‘ LES 
cia LT oai Le ERU Ebert hrs 2٦ ree مو لم‎ A 1 Re 
a y s 


« 
A A Ra M en. ا‎ 
sa [Td MILL ae Ei . Te Arie, e 
114. ^. a Hd ف9د‎ +4 























0 

















Et » 
A er ا‎ pag mg prey ete eT EL peti mus 
e 2 m £o) tte oia tinta V MP APRA AA AS 
" ioi Bad aid AA a md Lai are ru erp roe t Mnt A "e Ee rano ge? oni: erae 
"Va AAN k 


= Pride ag PAN ul 
reri ins omo رت‎ DTI ie of 
ا ا‎ ns se ke A ead inch 
dipl .یمج ےر سے لس رو اص‎ RA e OL LLL 
0 ai Md e Ni Po] + ا‎ i 

mappen rl pnp dr ae PARAS aod di reri bb bn s u 

vatam ann yerta senan eaa rhaa ee ee: ren =. 1 ar A. 
as LJ ee LTL G 
UA AE AA to ipod P: ya een 


ARE Pir RT TUE A 
"were ve bed. >» mu al 










"mL تہ‎ 
ا‎ keel AAA A O 
ATA اس‎ Poy ds 





























































































































































































































































































































































































































































































16 ی‎ 
dt Irae RAI : 
سر‎ ۲ lili AAA A AA ARES ad aranh >, eh a 
po PET re quoti f e unto a a^ e (29 o^ 4 G 0. 5 e qn m... > à 7 
rdi مہہ‎ RE IE rd pid y ae... 2. 21 o کر ہہ‎ 
" feres pisi i r ple Api qr bog عمج و‎ oe ee A. Le A te A au 
ا‎ irn d dir pi ARA rada اہ وجحمہ‎ ee pep ier 4 i Pus 0. 
A que e ipei جیا‎ rr trees ad OT aah 0 Li be ا‎ ah gente AR al run Gm ume e. TA A T gh 
prier trip e wr re d IRA prede POT T stead .. adela SEN "e E - e h 
A a ا دع‎ TS Er ce DIL NLD جن ”ام‎ a ae ^ ۳ : 
santa) AW OT ttr A Deere ARA AA 0, Lo ا اض ور‎ LIS , 7 
errr eT TO iau rrt pepe RA PAR ad] ۲ و‎ = AA " ۴ N art em 
ppt rp iio pocta v To aiti qiu A A EP r A o 22 ٹیا اس‎ gem H > Ar ي‎ 
Pl arial کر سو دی شر نچ‎ A DIE, . ri ula ole ج‎ A 4 APA ۴ E ما‎ DE 
ed together AAA d PARA ET ELTA TI A Liege abes edit Fal ما سس ری‎ SPER Fit RP e 
pum ار ںا رب سو ےا پا رای‎ dani ep u ar en ae ہیں‎ > A AL WT 
A ا ار‎ PI بی‎ wand ا م‎ N ARO TIA Hehe ER AA Seo Ne N 
وم صصصہرص‎ rior A iua iti quindi ovd ن‎ — v9 یجاب‎ a e x n 17 l4 ا‎ 2 $ H A 4 ve Pi ley A 
رس‎ EC Lidl AS PT ORTE TIL a v 4 d e t a, x Lou baie Dé xd M am - 
" re ri "ER Parr T I ا‎ ane 406 TS von a dm no 
FU dodi. pq o5 quem, vo "Ll ossia PE al hata JE OUTTA ٦ یں‎ d I nu DE D 4 ۰ 
AAA O a Ee ایی ا‎ lante RTS لاب میں‎ za} MS FI Lor ee 2 او‎ Rn ۰ 
ا‎ E heed de tp ET AL دم‎ di MIEL Ue > I ^ oe ey = مس سیل‎ E " 
ت ہے یرت‎ "ET ILLAD E A 0 19] y^. 1 
نو‎ eth. d omar dab wie ph فیس‎ sete . e ODDIE rs AT ا‎ SA eas ۔ وی‎ v 4 A ” E. Pr 
SN etal PARA ated et PEC: PET E دسر یر‎ Dac ^ = i D F 
رق راو ۳جس رر‎ y A pT E a pr ATA oro ihe eo T TE E ri UC n TETT 01ھ وو‎ sa œ 1 ۱ 
O A t uv per ipa hh did Red np tt a a اب‎ E T hue lage j n or » : M 
A کی سے د‎ o r رخ ا ا ا ا کا‎ Pe tae PT Leti AAA A Ld بی‎ * DIT + wt un. : 
"ure qe quocp P ue rr ا‎ IT d p bo حا ا ا‎ d dy ho^ ge ido fione یں‎ ar Hd AMA PETT TE 3 OUT 1 
frega gea A el PR A aaea ar" TET EEL سار یو پا با‎ EA e خیرم‎ 2 s xr 
bur 49 etate gut qr vnde TOT La PA dla M سر رت‎ TRE D E : 
O AA A A ordain aaa PROS ار رہ‎ vt t8 P ' 7 
IN bti ded P ipsae pe ULM e PT P A lee un A s 
AAA E a |. A rei ELE de r et ; Br 
a ص‎ e Is PA رای‎ ee "TS IL ا‎ 
TT PT o A e ek AS f 4 
ase wi A الا ا‎ pom Tenet pap E T e E a که وا‎ ree rer aid Le yr 
asd quas) njab ad cu Vt án an oid o ab arm Pad amb ul end 1 T TP TT APART a TTILE iaon : 
IA O و‎ TDI T a bid st مار‎ PME veil PSD cape pee P dl ta k : gr 
A A EU Dee یہ‎ athe ہو۔‎ ۶+ et pepe Mn atts = ^ 4 
PA Si ASA d P ا‎ iid 5 LI |i te» è ; P L nr 
pai A a oe SERA hed CP 2 T CT TEL AC A 
A دیو‎ u و لے لی‎ e T n aa e » Per TE ET "nae £ 
raging age r n are Bi na i P AA r TA ri - EN M 
aieo ash TE mae mra dba - AP IL oka ber P " uh 3 ; 
rg oe tr aa ee riel , pero rid aeuo iiid. PP rr: miter d RR RT) +s A 
حم ود ہے‎ po A A P ror SA T ML tn "HIE POET I e 1 7 D ےو‎ Y کا‎ 
AA ار‎ un UP ac IA adn me ا‎ mo : SA o e PP Tin یوب‎ d TAA "n^ ^ 
d deii سے‎ peppers A ا ار مر‎ AE idi سر کی‎ rad Mnt V PEE d pd ge prot @ ; 

A ARA لح اع‎ "mero TP db a pia pert wg i FC 7 8 Kin T 
p orsa a i Mmmm: a i» "ETT "TEIL UL hi oJ ٤ لی‎ f 3 ۱ 
دن رر وت رک‎ i مء هم‎ 7 eh ae : Db "PIT پیر ری‎ EL o , ^ 1 
———— کے‎ rd PI an DN To wegen A a رھ و سر کی‎ MES i i eh ale y 4 
E A ds جب یں اون‎ E O as APA A ہج‎ E a PI eoa vag mtr at) ^" A ۱ 
A E ا اد‎ PEL Eg ا ا کر ا ا و ا ا کک وا ا رما ہہ‎ PTE o hp P 4 mats Le ۶ 
ا یا‎ AAA AS DA AAN کا اک‎ de RARAS Pil E بی دس‎ A یس ۰ہ‎ A n 
grec aa PO en RE TER datei dp ete یہ‎ RD btt o AE A 
ATAR A AE el AS PC EIFEL rl of re borate Zi رج کر‎ = HESS Ie مکی‎ S 
ee ee A 105 ae eae Tt RO TS eh ii karten FRE PP AE haw e e is ا ا ا‎ i 
vo worm ec Peso Fe Ar وا‎ rr IO A p a D^ P TP ris Vii x p 
¿SU REA ISA A ا‎ id pro e Rion gs nhs alit ۰ ھی[ ۴ 0ھ ما نخس بہ امہ‎ LL ior s 
EE FFE eger E SOT q AAA m SUELE LE © " D A do +. 
تہ‎ AR A AR PD € HAC EIA THREE DS uL "ORF " 7 4 ا‎ < 

ps oI += C] y 1 y T (wer 1 aid 
PAS EAS 1 Le, ror qam ETC OTE "y 
اکا‎ desi iidem oral at Y S De prota dr dd ور ہم چس‎ y E 
Pas ae ate A TA poco) durs tern IPM. PTE TA E did F E 
AS -——À pun Pe d Pe ub. s TR Velden A : 
ERA ee nq E Ae RE EA ! نے ری‎ ' "TET, 
pe ime v^ et botte EE کا‎ MEER IMAGINE e » | Aaa ie Ae i , 
PRES, E EE AA چا سو‎ 1 A ES RE AL D TM P 
se e ns de a ANDE E ٠ 
Bos Sd, "Pt 
p i " à 
E E E LI es Ce . 
T بر‎ E 
یئ رر جرد تار‎ P i 
PRA PESTO TOA T " y 
کے ایح‎ A E E و‎ 
1 a. : t r 
í 4 ار‎ 
es Tar ore s a 
EA E a M 
perm 4 Fa | 
: j ^ 1 LI 
7 E رھ‎ 
7 D 
P 
h , . 
LL نع‎ 
موہ‎ yy 
٠ 
+ 
5 g 7 
"n IRL DL RM bd F 
GET UU CP ot پک‎ 
وید یر یی وی با رک‎ 2 
AS RE EAS 
T کر ار پر ری جج‎ "a A 
IO a 4 y TS JM 
"5 ا سای‎ 7 
PIRELLI IT IR N . fst ` ۹ کت‎ » aê $ 
LC Alei Ira HH as E * He Yi ‘ 
N d : OTE E r Ehe "P " LH " 
l5 A DET Su m. انا‎ ٤ 7 " H TZ E 
91a» afa M t mas “persue Sees ^ À A a airg o'k ES P 
و ےم‎ ui ach یو ور‎ M ھ7‎ Ar y 
TES O و چو‎ EE: م و سس رش خر‎ v 'a A 
وہ ود چھے۔ بد‎ T بد؟ یو‎ de «ips A des n رت‎ 
NUT ری‎ qa ato, * , LN " ۱ 
یریب لا شید یی ہراب بی ہر ہے ہیں‎ D 3 P F , 1 
po Sw is 1 ong, ORE Oe ST ELA " S F n Yin F er; 3 " 
sara ? su LLL ru r UT ما‎ ۹ ۹ TE 
y y pues ro 4۹ہ‎ er " y! 4 
Pau e c Sh " EA ee L کا‎ EEZ A E t a " "am 1. 
A do EE نو می ہا بت بت‎ PSI É S 4 ' 
Lebe i بلب‎ wur. ECTS EE Sy MES PCT, A ۰۰ "Tu wd E J 
A d d P و وة حي‎ e i ۰ “۰ E : 
A rd d ری سیر ہن‎ la à > PE om E D i 
T ELLE id i A e ln o hi mI ار‎ LLL E bl کچھ‎ 7 
"Tota لف ےت اھیسیر ینتج بے ہس‎ rin SEED ILC d N 
nn AL ا‎ u LE ETIN ٣۶ ML FL ' 
ہب‎ oa رر ود مد چپ لی‎ ts MARS . T 
محمد‎ ed a ol LEID A ^ 73 L d A 7 
تو و یی ی ا‎ zT m LET E 
abe ee odio ‚ah z : ۰ 
a TT O rahe F A T ۱ 
تیج کو ماپ‎ t 5 "TE TE 
ینیب ہہ رر رہ جیا ہد‎ i od ria y 1 E سو‎ 7 ٠ 
کہ ہیں می رش‎ dotada echoed بآ ہم ہس و‎ 4 OO EDD 
TS O aid dad E Md eaa PT he Tai e «g^ targ" n ہیی یں‎ UE E. A 
eda و اا‎ de dl dd ا‎ A iae] q. spin hs e Al MIT IE | OSO y i 
a > DT "EMI mn Ld EPI PLI Me POO ee - 40 TIA " 
ARA بیز اد‎ "7.9.59 cw RATOS a t TET nt ۰ دہ‎ rw A AC a 
L 1 پ یح‎ T AA TRAS LP ۾ ره‎ E 
ats Lehn tet Malahat wa Aa awin E MALAE EM LETTURE M y - 
ICE Leos) RA ah Bd ET IEEE 4 بی و‎ A E + 
SUN“ TD e lest پر بر ود تد ا ہیں‎ uu Pm 5 و۶‎ mw n ete we 
AS ا‎ adan de! dado G , ۱ 
ii he hd IED وف‎ 23) ate 4 
و‎ 
HEART + Try, a 
pena ich ow رر‎ I آے رس‎ 7 ¢ f & " 
MARTES A IA DC VITATE 
ise yir fm^ لف نو‎ mL x 1 ا یا‎ OOD ODI TID M ۴ a 
err et Cee ee te hoy «şew DIN SO پر‎ uns yi re TEL En TOT Hes 5 "M r - ٭‎ " 4 E 
ON PAE E de PEU O ر0‎ ' 6 MP s t) : 
tt OL hr Deh alin hd ye ae A y" 4 ور کٹ و‎ nt da 
youre DIU idus errors d 
SO La al 8 eee fev کیک‎ a. . 
ed M A bl je A ie 
St y "PI 3 
A ےنہر یر‎ dd, dr ا ا 1 ا ا‎ A "T 
n TALL E hid el A ral A A O تہ‎ TT. € 
اس‎ eni AA ir he ہ4‎ mper MIEL UAE MEL c | 7? 
A I Shan A BAR ric Reap vo at Te 
AA cS TC M 
ادا‎ ATANT IC O ald TID 2 
CUPIDE 
Li 











































"m 





LINER] 








ee Oe re Tre Lara D تی وو‎ 
LA de nl 
rm 





PIN Y 
کی و‎ 



































EL] ES eg at Ore Set 























































ae OSA CTS‏ .ہت 

o my nA e S ° ART yg tod یی‎ O À . 

X “۹ un‏ لوج پ ری ز تی Tre dedo di‏ را را ا o Lo hide‏ رو ں یج 

A ditm ےی رہ‎ LLL SI ا ا اق را ا ا ا ا ا ا‎ D Mod TT ER REEL CL La 

Ere ولس س ینوخ ہر ےش ری‎ As TD تی‎ AA ludi ui ss "ED 

LLL rr AR RA id a O A A O ا ا‎ 

n M TTE ded ie hdd ie DR P CATA LLL PD el LOSS TE رر‎ 

۵ کی ہج e mkan DÍS P nnram I SE aan LIE ado ey "ji tea e n Pw‏ را اہی اس 

e E E aa e bid eds FM‏ ا ا RER PR ST‏ چا 

A a Hee ll LEE £6) 

rr n ies H rr LS IS ie denia 

pn da ta dead AIDA A و‎ ERI Ld etit. 
DESEE TDi "e 
pene TT T d. d E A 


de NM » Jj h‏ بر ہی 
PT EEE Er du‏ 
Xen‏ 


a id do ii E رر ور‎ 


75 ل ایال دا‎ Dis id 
PA A A I de 


A‏ رت 













٤ی‏ مہ جج بج . 

aa a ie :‏ اک ا a‏ ےرا ےج 

AAA A Ke disi Rog: Feet favo f dé vip p y P UL] edin epi 09 LIT LA) a E € 

Magen nodu Andino Jeudi eid ۷ے جوووم ۱۰۸۱478۰6۲۰۲۶۰ ۶ بوظم بد ے1‎ i oydagi fanof fa ید‎ ies Li i 

AA O T A A LS LET 
M dts ERUIT M I LONE LE 


hc بیز رہ رن رآ‎ [RII تے‎ E, 
ii a aa ite Arm IE n 
eoi LA EL را اج ا اہو‎ Uere برای‎ 
LI oe] JA A AA ab ERE UA 
AS TE! AO انیو تسین‎ mole LET ob ds "E "m 
A C Aft e idas NAS AA LA Peta 
ااا‎ e y TU ا‎ a dd dd dd CIL O Ad TILL AA AS 
A o A DL ded hd u ET lied af eres tri Fe. tafe o. o2 2 a 
AA ETTET is A کل و‎ bed ا‎ IS LL D 
PTE UL da ii NETA O کل‎ EEN AA A E TL N T 
b Db diit lb Agir eerte Ye eher Tar cf Sate Ch bibs hhh pee aii ee میں یں‎ Le MTM g 
y AA AO cce PIT A ور‎ MV A 0 e A 
A ETD UE ^ N DTT La LL ae 
OU a ts e IN اک‎ ud adc reed AE TA AA HTTP Lédi J- 
یی وف ےک مر و شا وویھے۔‎ y ار‎ LIED 
sey Ê PETE IE BTL EEE 


PCT wi TELE LU. 
DA Fute 
SAT و‎ 





tr TY A TONI 
ri 


یسل ish dd‏ ہب رر or‏ 
وی دوہ qå‏ 

















































oat E M LAN] 

er th a 
“ou ds 
A E 
ste vati 


























han de BL EEE JS Zune‏ رنیر ہو لںر 
qe td ee fe A eee [7 RR I IM A Lai Lc‏ 
re PEN‏ نوا سیر و LR de lo di dida de AR a APA A‏ 
AI dad A E PE aS A DA DE a "UNA ARE]‏ 
PTAS IA LÀ fr‏ 





Tobia io PII MP Ll جات جج‎ LIE wr eta PU WIR Pa P 

ASE da prr dd 7 MA Ld. M i CYTCIZA T DIU E LLL d REIZE H 

AA A a aa Pr a d CO زور رو‎ PAR AAA RA TT (o) ê CO o, wee | 
"aS ose 99! (o rum tat be LA e fure ros و‎ Lad ivre ray Fe n 

















سم و رن T a‏ 































tel ated Bt WA LE‏ و چ و رپ ےل 
n‏ میم ہہ a ee id OO Led p apad Rah DD OANA‏ 
ls]‏ لھڈ T A‏ لی A SS E dr id pipra PIDE AL ER sad EL‏ 
uU fe xv‏ بی پر ee ar LITO di Lî A‏ 
CENA “era MITUITICTIS [ERE EET) Dub 0‏ 
icf a‏ 





IT RE» 
$9,947 € ov mew? 
Las a A dl E 


RN TE و‎ 

PA ا‎ se Ah eee yr Cl ret ett TTE SLU iam I) 
Ad Mate ferret Tt feda a ari He LITT eT ee ay | Cate Gd i REL Le 

ex ARAN AAA ALA وو تا(‎ 


بر ور ا ا ا ےا pas‏ 
ری ما ا ی لس d‏ چھ 8٠۷۱۰۱۵‏ ۶7 رت nz‏ 
Loi‏ 























pen rn ee eat nd byte 
مم‎ T LUE ng PO یرام‎ abd iT 
Per rt hor ah Se We 2ER FE زیر یرہ تی‎ bf ol te ET Poe 
Sea eel rê RA 
انمت بن اہی‎ apre 2H ria i dcl vi qi. 
روا ایت‎ AR Dri J یٹور پر یں بے ہہ‎ 
EA A A Ae Tia E Um rupem AA T 
u [DIN URS Gs 









Cages der cd ia‏ رو یی یک ہر 
hh oe bk‏ 


LÀ 
eT TT DD TAL rr ol hd 7 LIP TII A AE sera ys o d f 
ja di NR A dd Bt re) 4 TD VES وب سای یں ای وج‎ ۶ 
rew iot A AA E RS A A di AA d 9$ E 
"6 ا‎ thee Ch ce ohh had اک یا‎ ei AAA ا و‎ A? سیت وا ا ہے اک ا نو‎ ° g1 7, 07 
فی وی وای یا د ی ا‎ BE TD a IT I EEE EL جا می‎ pda HM S SEU اوس یں کہ‎ A IL 
ری ا ا ا‎ iiie pec dd تک‎ LE Le RIA ہہ وہ‎ la dera he UL LDL PIT x 4d. 
a id AA da od a UAR E UU Ted tt dd Hur HET LAL ASL EASA ASI U QR LLLA 
OS al A en ut Aad رتا وی‎ A LALA d ron ee 
| ce 9116 dori 







ld di scd 
یلہد‎ 






















vifu"‏ اسان عیب سی لی نر امو 
PRIUS tn A e elabi tut pl y vis Ud‏ 
بیھز نر تار ید eed‏ ریس یروف ہت میں سر S Prades i dian e A er D Aid. Y‏ 
rhs AT AL dE MM me po Cro m TE SO‏ 1 یی A cido A N pepe ied‏ 
LAA a o ro y IIA $‏ تنیز یر لہ e a A‏ 
da e RP‏ انیل Pitt ALA al‏ 







dea d iris Baal hid Melb LAN " 
a dic dad irs ere bd db edd "XL n dae LA td bb V (fob egy f shy 
n r‘ y> رض سد‎ PT Dg AU E LA e d M a نم ری‎ Y A IDA 
Der a a AD e ne نیما سنہ ہنی‎ Pey TCR nn i un wi all, 
ihe d LU سی‎ i 0 ce a ENT TE PETER 
oe DT LL De ہو‎ EL 4 be fne drer TAA LA 
ہے ہی‎ TT I o PEL ARAS AAA SA 2 


ios e EE s e [4 59) 998.4 تین بر ہی ہی پر باب‎ | 
DETTA ACHES SAG aL ea [4 
* n osi 





















A OS لے‎ 
Sams TALA 

















pprt EAR MEL ded or yer ary dl 2 
e ae Ria xt 
ries n ALEA de ua A ALT A. a é 
سپ ریا‎ RA HE 3 93 d "Tu Meere یا‎ 
وب کا کردا‎ EUER TUA T M v a mnc ois s سور ری‎ 
pr o ASIA EA A AEE & Ak AAA Ai mat AO DATIL 0 
eS > E CA Gia 0 f : 1 










































Conversion of mass storage hierarchy in 


MAL UU AU M 


3 2768 000 81800 9 
DUDLEY KNOX LIBRARY 


iv 


i 


